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PREFACE 


The Document Interchange Architecture (DIA) provides document interchange 
capabilities across a broad spectrum of IBM office systems and is the 
communication architecture between DIA application programs. Specifically, DIA 
defines the protocols and data structures that enable programs to communicate 
processing intentions and interchange data. DIA logically divides into several 
parts: an information interchange base and various DIA application services. 
The strategic architecture for physically transporting data between products is 
the System Network Architecture (SNA) LU 6.2. This manual describes the use of 
the SNA LU 6.2 protocol boundary (LU 6.2 PB) by DIA application programs. 


This manual is intended for data processing managers, system analysts, 


designers, system programmers, application programmers, as well as systems 
engineers and product support representatives. 
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CHAPTER 1. INTRODUCTION 


This document is intended for use by programmers responsible for designing DIA 


programs which use LU 6.2 for communications with other DIA programs in a SNA 
network. | 


In a SNA network, a DIA program is one of several programs called SNA Service 
Transaction Programs. The DIA program in LU 6.2 is known as the Document 
Interchange Model with reserved Transaction Program Name (TPN) of X'20F0O'. The 
phrase DIA program or DIA transaction program is used in this document to be 
consistent with related documents and historical use. DIA program always means 
Document Interchange Model in LU 6.2. 


This document describes the mapping of DIA sessions and transaction level 
command/reply logic to use of specific verbs (or verb sequences) at the LU 6.2 
protocol boundary. It also defines the detailed rules which must be followed in 
all designs to insure a consistent use of the LU 6.2 protocol boundary across 
all DIA implementations. 


WARNING: Failure to use these rules may result in logical lockout of 
communications or DIA program failures and are done at the risk of the 
implementer. 


The information contained in this document is organized as follows: 


e "Chapter 2. DIA Transaction Program Concepts" on page 3 presents an 
overview of DIA/LU 6.2 program relationships and highlights key concepts in 
DIA application program design. 


e "Chapter 3. Definition of DIA Processing States" on page 9 provides a 
description of the DIA transaction program states and relates them to the 
conversation states of the LU 6.2. 


e "Chapter 4. DIA Rules for Using LU 6.2" on page 13 specifies the rules 
which must be followed by all DIA/LU 6.2 designs. These rules are described 
in terms of program states and the use of specific verbs or verb sequences 
at the protocol boundary. 


A table is also provided in this section summarizing the allowable use of 
verbs and specific parameter values by DIA programs. 


e "Chapter 5. DIA/LU 6.2 Protocol Machines" on page 21 provides a finite 
state machine description for enforcing the DIA/LU 6.2 relationship rules 
specified in this document. 


e "Chapter 6. DIA/LU 6.2 Data Flows" on page 29 provides detailed scenarios 
for each of the commands defined by the DIA architecture. Each scenario is 


preceded by a state diagram showing the flow of control and data for that 
command. 
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CHAPTER 2. DIA TRANSACTION PROGRAM CONCEPTS | 


DIA is the architecture used to interchange requests and replies between two 
processes. It is the set of conventions which allows office system functions to 
be distributed across a variety of products. The specific functions of document 
distribution, library services, and application support are described in related 
documents. DIA is the orderly exchange of request and reply information that 
causes the transaction programs to perform these functions in a coordinated way. 
The request and reply information is exchanged in data stream constructs defined 
by DIA. These constructs, called Document Interchange Units (DIU), are defined 
independently from any product-specific application program interfaces (API) 
used by processes to send and receive DIU entities, and independently from 
specific communication facilities used to provide connectivity between the two 
DIA session partners. 


DIA USE OF LU 6.2 SERVICES 


LU 6.2 is the strategic IBM architecture for SNA process communication. It has 
been designed to satisfy the needs of a wide range of products from host or 
system-level products to device-level products. In its simplest terms, LU 6.2 
is designed to facilitate synchronous transaction-program-to-transaction-program 
attachment, resource allocation, and conversational flows for as short or as 
long a period of time as desired by the programs. The protocols provide for 
information integrity across a multiresource scope and provide recovery design 
in the event of communication failure. These characteristics of a communication 
support system are required by DIA implementations and were assumed in the 
design of DIA. 


LU 6.2 Transaction Programming Environment 


Figure 1 on page 4 depicts the overall relationship of the DIA architecture to 
the architecture provided by LU ei 2, as seen from the DIA transaction 
programmer's point of view. 
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SNA COMMUNICATIONS FACILITIES 


Figure 1. DIA/LU 6.2 System Relationships 


Within a particular system, the DIA transaction program exploits system 
resources to perform functions. Some of these resources are local and outside 
the scope of LU 6.2. Other resources, particularly the LU 6.2 conversation with 
the remote DIA transaction program, are allocated by verbs and protocol of the 
LU 6.2 protocol boundary. 


A particular instance of a DIA transaction program does not ordinarily have more 
than one LU 6.2 conversation. This conversation may contain only one request © 
and reply or a long series of requests and replies. The resources required to 
perform these functions, such as library space and subordinate programs, are 
invoked by local interfaces. 


The initial DIA transaction is stimulated through some interface to perform 
functions. These functions may require a conversation with a remote DIA | 
transaction. The initial DIA transaction is the requestor of the LU 6.2 
conversation or the session resource. When all information exchange is 
completed normally, it is the same initial DIA program which terminates use of 
the session resource. The concepts are illustrated in Figure 2 on page 5. 
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Figure 2. DIA/LU 6.2/Resource Relationships 


LU 6.2 Transaction Programming Interface © 


The transaction programmer's interface to the LU 6.2 services is described in 
terms of verbs issued at the LU 6.2 protocol boundary. The verbs provide a 
semantic definition of the way that programs interact with SNA Services and are 
documented in Transaction Programmer's Reference Manual for LU 6.2. Products 
implementing LU 6.2 do not have to provide an interface which exactly matches 
the LU 6.2 protocol boundary. However, program communication interfaces which 
do exist in LU 6.2 products must be able to be mapped into the LU 6.2 protocol 
boundary. 


In this document, the DIA transaction program rules for using the LU 6.2 
protocol boundary are described in terms of the syntax and semantics defined in 


Transaction Programmer's Reference Manual for LU 6.2. All references in 7 
Transaction Programmer's Reference Manual for LU 6.2 regarding the treatment of 
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logical records may be equated to the handling of the DIU data stream components 
described below. This document assumes reader knowledge of the LU 6.2 


conversation states and semantics defined in Transaction Programmer's Reference 
Manual for LU 6.2. 


DIU STRUCTURE 


The overall DIA Document Interchange Unit structure is shown in the figure 
below. A valid DIU consists of the following logical components: a DIU prefix, 
one or more DIA commands in a command sequence, data units, document units, and 
a DIU suffix. Each DIU component (or subcomponent) is a self-defining, variable 
length structured field that has been assigned a registered 2-byte identifier 
(ID). (See DIA: Concepts and Structures). The syntax and semantics of 
structured fields used in DIA are owned, maintained, and enforced for cross 
product use by IBM. ) 


<——— DOCUMENT INTERCHANGE UNIT (DIU) ——-———» 
DIU DATA DIU 
PREFIX UNITs SUFFIX | 


Figure 3. DIA Document Interchange Unit 

The DIU prefix is used as a data stream delimiter which begins and identifies 
the DIU. The DIU-ID field of the prefix is used as a correlation value which 
permits a DIU sent in reply to be correlated to this DIU. 


COMMAND 
SEQUENCE 


DOCUMENT 
UNITs 


DIU Component Definitions/Usage 


The command sequence portion of the DIU contains one or more DIA commands which 
identify the functions to be performed. Each command directs the process to 
which the DIU is sent to perform some function or to act upon the data in a 
specific manner. Execution of the commands in the command sequence is the 
responsibility of the receiver of the DIU. The operations requested by the 
commands must be performed in the order in which the commands appear. The 
meaning of each command and its required replies, if any, are specified by DIA. 


Data units contain information that is referenced by one or more commands in the 
current command sequence. Data units may be thought of as indirect or factored 
command operand values. 


Document units carry the information which is the object for one or more command 
operations specified in the command sequence. The ID fields of this data stream 
component indicate that this is a document unit construct and denote the type of 
document unit. 


The DIU suffix delimits the end of the DIU data stream. The type of suffix used 
determines the disposition of the data stream as follows: 
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. DIU suffix Type 1 indicates normal termination of the DIU data stream. 


¢ DIU suffix Type 2 indicates that the sending application of the DIU 
encountered an unrecoverable DIA exception condition during the sending of 


the DIU. The DIU data is thus invalid and should be purged by the receiver 
of the DIU. 


NOTE: It should be remembered that the cause, scope, and recovery 
procedures for DIA exceptions are independent of LU 6.2 ABEND conditions or 


return codes. These two distinct levels of error conditions should not be 
confused. 


The reader should refer to the DIA: Concepts and Structures for a detailed 
description of DIA data stream component semantics and syntax. 


DIA COMMAND/REPLY PROTOCOLS 


The essence of DIA is the set of commands which define the functions to be 
performed when they are exchanged between DIA applications. Architecturally, 
the DIU may contain one or more commands contained within a command sequence. 
Some implementation versions constrain the command sequence to only one command. 


There are two classes of commands for which distinct reply protocols are defined 
for DIA. 


No-Reply-Required Command Class (NRR) 


This command class is defined to let one DIA process convey information 
to another DIA process without requiring a reply to the command. 


Synchronous-Reply-Required Command Class (SRR) 


This command class is defined to let one application request that 
another perform a function with that application necessarily replying to 
the request before any other interchange of requests is permitted. 


Asynchronous-Reply-Required Command Class (ARR) 


This command class is defined to let one application request that 
another perform a function when the reply to the request is not required 
before any other interchange of requests is permitted. 


A replying command is a command that contains the CORRELATION operand. This 
operand indicates that the command is a reply to a previous SRR command and 
provides the data necessary to correlate to that reply required command. 


DIA EXCEPTION HANDLING 


The objective of DIA is for two application processes to exchange information in 
a reliable manner. The processes must be capable of recognizing when a Document 
Interchange Unit (DIU) is received with errors that are detected at a lower 

level such as the SNA communication facility. DIA is dependent on the fact that 


ne 4 
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the layers of support below the application level will notify the application 
process when a permanent error exists. This lower level includes the SNA layers 
for link level control and network services. SNA defines the alternatives for 
handling error conditions at that level. DIA assumes that all error procedures 
have been attempted by the component layers below the application programs and 
that unrecoverable errors are presented to the process application for final 
disposition. 


The damage assessment process for a DIU with a permanent error is to interpret 
and evaluate the DIU entities to determine if the request can be successfully 

executed. If exceptions are detected and all of the recovery techniques have 

been unsuccessful, then the DIU cannot be reliably processed and the receiving 
process must terminate DIU processing. 


The DIU analysis process consists of algorithms that evaluate the DIU syntax to 
determine which functions of the DIA repertoire are to be performed. This 
evaluation may discover syntax and semantic exceptions. The syntax exceptions 
are deviations from the defined structure formats, missing parameters, parameter 
values outside permitted ranges, and DIU entities incorrectly encoded. Semantic 
exceptions are usually detected when a requested operation is activated and some 
violation prevents successful completion. There is also a distinction between 
errors and exceptions. Errors are those failures that occur at the program or 
systems level. Exceptions are violations of the architecture that are detected 
in a DIU without, necessarily, an indication of a failure by a system or 
application component. 


The syntax and semantic exceptions that prevent a requested DIA application 
process from being normally completed must be reported to the sender of the DIU. 
The ACKNOWLEDGE NRR command with an EXCEPTION CODE operand is used to report 
exception conditions detected by the receiver of a DIU. If there is an 
exception condition detected in the DIU containing the acknowledgement of the 
sender's request, then the DIU processing is terminated, the detected exception 
is sent by ACKNOWLEDGE, and a SIGN-OFF command is sent. Exceptions that are 
detected by a sender that prevent successful transportation of a EOMDIEES DIU 
are specified in a form of the DIU suffix. 


If an exception condition which prevents execution of the DIU function occurs 
while a DIU is being received (local LU 6.2 is in receive state), the 
ACKNOWLEDGE with exception code may be sent immediately, using the LU 6.2 
SEND-ERROR verb to indicate the error condition, the LU 6.2 SEND-DATA to send 
the ACKNOWLEDGE data, and a RECEIVE AND WAIT to be ready for the next recovery 
step. 
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CHAPTER 3. DEFINITION OF DIA PROCESSING STATES 


The dialogue that takes place between two DIA transaction programs may be 
described in terms of processing states. These states are updated during the 
processing of DIU command sequences and apply to all DIA function sets. 


A DIA session is a DIA unit of work which lasts from DIA SIGN-ON to DIA 
SIGN-OFF. A DIA session exists on a LU 6.2 conversation. An LU 6.2 
conversation is an instance of use of a LU 6.2 session. Thus, the LU 6.2 
session is a resource used to support the DIA session. | 

The DIA processing states may be divided into two major categories: 

e Session states which relate to establishing and terminating the DIA session. 
° Command states which deal with managing the DIA request/reply command flows 


during an active DIA session. The states in each of these categories are 
described below. ? 


DIA SESSION STATES 


The following convention is used in these definitions. The symbols <name> 
specify the state name. 


RESET: 

<RESET> 
A conversation between two DIA processes is not allocated and no 
DIA session exists. This is the initial program state of a DIA 
process. | 

NOT ACTIVE: 

<NOTACT> 
A conversation between two DIA processes is allocated, but no DIA 
session exists or is pending. The DIA partner which allocated the 
conversation may now send SIGN-ON. 

PENDING: 

<PEND> 
A conversation between two DIA processes is allocated and DIA 
SIGN-ON SRR has been sent or received. The DIA session is 
pending. 

SONR_ SENT: 

<SONS> 


A conversation between two DIA processes is allocated. A SIGN-ON 
NRR reply has been sent to indicate acceptance of a SIGN-ON 
request or a SIGN-ON NRR request (allowed only for migration by 
existing DIA implementation to effect mid-session change of 
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IDLE ACTIVE: 
<IDLE> 


QUIET: 
<QUIET> 


process roles) has been sent to change DIA session parameters. | 
The process is in RECEIVE state waiting for a DIU to start the DIA 
session flow. 


This state applies only to the process receiving an initial 
SIGN-ON request, or the process sending a mid-session SIGN-ON NRR 
request to change DIA session options. 


A conversation between two DIA processes is allocated and the DIA 
session is established. The processes at either end may send or 
receive commands, depending upon the roles defined in the SIGN-ON 
command. 


The DIA session parameters are‘preserved outside of the DIA 
transaction program and a DEALLOCATE verb has been issued. No DIA 
activity is possible until an ALLOCATE verb from one DIA program 
generates a LU 6.2 conversation with a DIA program equivalent to 
its former remote partner. This is possible in two special cases. 
Case 1: Connection to an equivalent instance is possible when 
there is only one possible DIA transaction program instance in the 
remote LU. Case 2: Connection to an equivalent instance is 
possible if there is only one possible LU 6.2 session from the 
local to the remote LU; and when that session is used for 
conversation between DIA programs, the equivalent DIA programs are 
always evoked. This implies the recipient of the ALLOCATE 
generated LU 6.2 protocol must make the original DIA session 
parameters available to the newly allocated DIA program and the 
program uses these to put itself in the IDLE-ACTIVE state. Case 2 
is known as the "single session assumption". 


DIA REQUEST/REPLY COMMAND STATUS 


SRR_SENT: 
<SRRS> 


SRR SENT & 
SRR-RECEIVED 
<SRRSR> 


The process has sent an SRR request and is awaiting a reply. 


The process has sent an SRR request and has received an SRR 


replying command. The process must now send a reply to the SRR 
reply received. : | 
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SRR RECEIVED: 

<SRRR> 
The process has received an SRR request and must provide a reply 
as the next command sent. 


SRR RECEIVED: 
&SRR_ SENT 
<SRRRS> 


The process has received an SRR request and has returned an SRR 
replying command. The process is awaiting a reply to the SRR reply 
sent. 
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CHAPTER 4. DIA RULES FOR USING LU 6.2 


This section details the rules which must be followed by DIA implementations 
using the LU 6.2 protocol boundary. The rules are described in terms of DIA 
states, DIA commands and command classes, and the specific verbs or verb 
sequences issued at the LU 6.2 protocol boundary. 


A table is also provided summarizing the allowable use of verbs and parameter 
values which may be used by DIA applications, along with the ground rules for 
using optional verbs, if any, provided by the local LU 6.2 Service Manager. 


RULES FOR USING ALLOCATE/DEALLOCATE 


DIA uses the ALLOCATE/DEALLOCATE verbs to establish and terminate conversations 
with remote DIA transaction programs. The points within the DIA session where 
this may occur are defined in terms of DIA states. 


A conversation must be allocated prior to sending a SIGN-ON command requesting a 
DIA session and may be deallocated when the DIA session is concluded. The 
conversation may also be deallocated within the DIA session when one of the two 
session partners wishes to enter a state of inactivity. This state is called 
the QUIET state in DIA. 


The QUIET state is used by implementations for a variety of purposes which are 
independent of the semantics of the DIA architecture. For example, a work 
station product may choose to enter the QUIET state to accommodate a swapping of 
END USER interface programs prior to resuming DIA activity. A host DIA program 
may wish to enter the QUIET state to allow swapping or rollout of the program to 
occur for sharing of the core resources with other programs. 


When the DIA session is in QUIET state, the conversation must be reallocated 
before the DIA session can be resumed. This is accomplished by issuing ALLOCATE 
to establish the conversation. As explained above in the definition of the 
QUIET state, it is the responsibility of the DIA session partners to correlate 
this conversation to an already existing DIA session. 


The following rules apply to DIA's use of ALLOCATE/DEALLOCATE: 


e ALLOCATE is issued in the DIA RESET state to establish a conversation for a 
new DIA session. The TPN value specified must be X'20FOFOFO', (DIA), and 
the TYPE specification must be CONVERSATION. 


° The DEALLOCATE verb is issued in the DIA NOT ACTIVE state to release the 
conversation at the conclusion of the DIA session. The TYPE specified when 
DEALLOCATE is issued in this state should be SYNC LEVEL. 


* DEALLOCATE is issued in the DIA IDLE ACTIVE state when the program wishes to 


enter the DIA QUIET state. The TYPE parameter value used when DEALLOCATE is 
issued in this state should be SYNC LEVEL. 
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ALLOCATE is issued in the DIA QUIET state prior to resuming DIA activity. 
The LU NAME, MODE NAME will be used as a way of correlating conversations 
for implementations which make the single session assumption. 


DEALLOCATE is also issued by DIA exception handling processes when 
unrecoverable process errors are detected. (See "Rules for Handling 
Exception Conditions" on page 15.) 


FLOW CONTROL RULES 


The rules for controlling the DIA command flows in LU 6.2 implementations are 
summarized below. 


1. 
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The process which allocates the conversation is the DIA process which sends 
the SIGN-ON request. The SIGN-ON request must be sent in the SRR command 
class using SEND DATA and must be followed by issuing RECEIVE AND WAIT. 


If the SIGN-ON request is to be rejected, the receiver of the command must 
issue a SEND ERROR verb followed by a SEND DATA verb which sends an 
ACKNOWLEDGE reply with exception codes which describe the reason for 
rejection. There are two cases for the SIGN-ON sender to consider: 


a. If the ACKNOWLEDGE reply is sent followed by a DEALLOCATE TYPE 
(SYNC LEVEL), the sender of SIGN-ON must deallocate the conversation and 
enter the DIA RESET state prior to initiating any new requests for 
session. 


b. If the ACKNOWLEDGE reply is sent followed by RECEIVE AND WAIT, the 
sender of SIGN-ON may either resend SIGN-ON with new DIA Session 
options, or deallocate the conversation and enter the DIA RESET state. 


In the latter case, the remote program is notified of a normal deallocation 
through the return code of RECEIVE AND WAIT. The remote program should then 
issue DEALLOCATE TYPE (LOCAL) and enter the DIA RESET state. 


If the DIA SIGN-ON request is accepted, the receiver of the command must 
send a SIGN-ON NRR reply. This should be followed by RECEIVE AND WAIT in 
order to provide the sender of SIGN-ON request with the first opportunity to 
send commands within the session. 


Upon receiving the SIGN-ON NRR reply, the SIGN-ON sender may relinquish 
first send control to his session partner, if desired, by issuing 

RECEIVE AND WAIT in the DIA IDLE ACTIVE state. This invites the remote DIA 
Session partner to send the first command in the session. The DIA SIGN-ON 
request sender is given first opportunity to send commands on the assumption 
that the SIGN-ON request sender has the best idea of what work needs to be 


done on this session. 


The receiver of DIA commands may request to be the command sender by issuing 
the REQUEST TO SEND verb. This verb may only be issued in the DIA 
IDLE ACTIVE state. 7 
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Upon receiving notification of the REQUEST TO SEND, the local program may 
grant control to the remote program by issuing RECEIVE AND WAIT in the DIA 
IDLE ACTIVE state. The local program, however, may elect to retain control 
and continue to be the command sender. 


5. DIA command sequences, other than those allowed in the DIA/LU 6.2 Protocol 
Machines, are in violation of mapping rules. The process detecting an © 
invalid command sequence will issue SEND-ERROR followed by DEALLOCATE TYPE 
(ABEND). See the section entitled DIA/LU 6.2 Data Flows. 


6. Either process may enter the DIA QUIET state by issuing DEALLOCATE in the 
. DIA IDLE ACTIVE state. 


7. Either process, with something to send, may cause a session which is in the 
QUIET state to be resumed by issuing the ALLOCATE verb. The DIA session is 
resumed with the process issuing ALLOCATE in the DIA IDLE ACTIVE state and 
the other partner in the DIA IDLE ACTIVE state. 


RULES FOR HANDLING EXCEPTION CONDITIONS 


Exception conditions and corresponding recovery actions are defined by the DIA 
architecture. The following rules apply to how these exception conditions are 
reported using the verbs of the protocol boundary. There are three general 
cases to consider: 


: Exception conditions detected by the DIU receiver 

. Exception conditions detected by the DIU sender 

. Process or program exception conditions detected by either program partner. 
The actions required in each of these cases are defined below. 


. Exception conditions detected by the DIU receiver are reported to the sender 
of the DIU by issuing a SEND ERROR verb followed by a SEND DATA verb which 
sends an ACKNOWLEDGE replying command with exception condition codes 
describing the exception conditions. 


The sender is notified that an exception condition has been detected through 
the RETURN CODE parameter of the LU 6.2 verbs. The program must then issue 
RECEIVE AND WAIT to obtain the information about the exception condition. 
The Correlation operand on ACKNOWLEDGE is used to correlate the exception 
condition data to a specific DIU sent. 


. Exception conditions detected by the DIU sender during the sending of DIU 
information are reported to the receiver by terminating the data stream 
being sent with a DIU SUFFIX type 2. The SUFFIX carries information 
concerning the type of error detected. 


If a DIA logical record which contains an exception condition has been 
partially sent, then action must be taken to insure that the remote program 
is able to scan the data stream. This may be done in two ways. DIU 
receivers will support both methods. 
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The first method is to complete the sending of the DIA entity in error prior 
to sending the DIU SUFFIX logical record. The second method is to issue a 
SEND ERROR verb, followed by a SEND DATA verb which sends the DIU SUFFIX. 

In the second method, the truncation handling protocols of the LU 6.2 verbs 
are used to insure the scan of the data stream by the DIU receiver. 


Catastrophic process or program errors may be detected during the execution 
of either program partner. These errors usually indicate errors in program 
logic and are not recoverable. When a DIA program detects a catastrophic 
error of this type, it attempts to gracefully terminate the conversation by 
sending a SEND ERROR prior to issuing DEALLOCATE TYPE (ABEND). 


RULES FOR USING SYNCHRONIZATION PROTOCOLS 


DIA/LU 6.2 implementations are required to support the synchronization protocols 
described in this section. In particular, programs may issue DEALLOCATE 

(SYNC LEVEL) to synchronize the ending of a DIA/LU 6.2 conversation; programs 
will respond properly to CONFIRM requests presented at the protocol boundary via 


_the WHAT RECEIVED parameter returned on RECEIVE AND WAIT. 


DIA applications are also allowed, but not required, to issue the CONFIRM verb 
at the conclusion of each request/reply command sequence if so desired. 


The following rules apply to DIA's use of SYNC LEVEL protocols: 


DEALLOCATE TYPE (SYNC LEVEL) should be issued by a DIA process prior to 
entering the QUIET state. This verb may only be issued when the process is 
in the DIA IDLE ACTIVE SEND state. 


The purpose of this rule is to insure that the last command or reply sent 
has been received and processed correctly and that the application states of 
both programs are consistent before the conversation is allowed to 


terminate. 


A SEND ERROR, SEND DATA of an ACKNOWLEDGE command data flow will be returned 
if the last DIA command or reply sent was found to be in error. 


The SYNC LEVEL operand must be specified when the DEALLOCATE verb is issued 
following the sending of the DIA SIGN OFF command. 


The purpose of this rule is to insure that the remote program has received 
and processed the SIGN OFF and has reset to DIA Not Active state conditions 
prior to the termination of the conversation. 


A return code of ok indicates that the remote program has been reset to the 
DIA Not Active state and has issued CONFIRMED. A SEND ERROR, SEND DATA of 
an ACKNOWLEDGE command data flow will be returned if a catastrophic 

exception condition has been detected in the processing of the SIGNOFF DIU. 


CONFIRM may only be issued when the DIA program is in IDLE ACTIVE state. 
The smallest logical unit of work which can be synchronized within a DIA 
session is a request/reply command sequence operation. A request/reply 
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command sequence operation includes the processing of the command request 
and return of any required synchronous replies. 


° Programs receiving a CONFIRM request are required to complete the processing 
of all DIU data received. If exception conditions exist in the data, they 
are detected and reported by SEND ERROR, SEND DATA of an ACKNOWLEDGE (EC) 
data flows as part of the normal DIA application processing of DIU's. 


If there are no outstanding synchronous replies required after all DIU data 
received has been processed, then the program responds to the CONFIRM 
request by issuing CONFIRMED. 


If there are outstanding synchronous replies required to conclude a command 
request, then the command operation cannot be confirmed. The program will 
respond by issuing SEND ERROR followed by DEALLOCATE TYPE (ABEND). 


DIA USE OF VERBS AND PARAMETERS 


The tables in this section show the verbs and parameter values which DIA 
programs may use in LU 6.2 implementations. The Transaction Programmer's 
Reference Manual for LU 6.2 contains the detailed description of the LU 6.2 
verbs and parameters. The value specified in each parameter is the DIA value 
prescribed for support on the office system base. 


Optional Support Requirements 


DIA implementations are permitted to take advantage of performance verbs offered 
by the local LU 6.2 Service Manager only if the resulting LU 6.2 internal flows 
to the remote program are identically equivalent in every way to the usage of 
verbs on the LU 6.2 base. 


DIA implementations are also permitted to use other locally available LU 6.2 
Service Manager options which do not have a session visible result, that is, are 
totally transparent to the remote program partner. 
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The use of local LU 6.2 Service options, as described above, is a product design 
decision. 


ALLOCATE 
RETURN CODE (variable name) 
RESOURCE (variable name) 

LU NAME (OTHER,*) 


The value placed in the 
variable name supplied 
in RESOURCE is needed 
in all other commands 
which refer to this 
RESOURCE. The same var-— 
iable name should 
therefore be provided. 


TPN (X'20F0') 
MODE NAME (other than SNAVCMG) 

RETURN CONTROL (WHEN SESSION ALLOCATED) 
SYNC LEVEL (CONFIRM) 


DIA TPN 


GET ATTRIBUTES 
RESOURCE (variable name) 
PARTNER FULLY QUALIFIED LU NAME (variable 
name ) 
MODE NAME (variable name) 
SYNC _LEVEL (variable name) 


Values filled as a re—- 
sult of execution. 


DEALLOCATE 
RETURN CODE (variable name) 
RESOURCE (variable name) 
TYPE (SYNC LEVEL) 

TYPE (LOCAL) 
TYPE (ABEND) 


CONFIRM | 
RETURN CODE (variable name) 


RESOURCE (variable name) 
REQUEST TO SEND RECEIVED (variable name) 


CONFIRMED | | Issued in response 
RESOURCE (variable name) to CONFIRM. 


Figure 4. DIA Use of LU 6.2 Verbs (part 1 of 2) 
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SEND DATA 
RETURN CODE (variable name) * * Values are placed in 
REQUEST TO SEND RECEIVED (variable name) *| these variables as a 
RESOURCE (variable name) | result of execution. 
LENGTH (variable name) 
DATA (variable name) 


RECEIVE AND WAIT 

RETURN CODE (variable name) * 

REQUEST TO SEND RECEIVED (variable) * 

RESOURCE (variable name) 

WHAT RECEIVED (variable name) * 

LENGTH (variable name) Max length converted to 
actual length as a re— 
sult of execution. 

DATA (variable name) * 

FILL (BUFFER) Specify receipt inde— 
pendent of logical 

FILL CLL) record structure. 


REQUEST TO SEND 
RESOURCE (variable name) 


SEND ERROR 

RETURN CODE (variable name) 

REQUEST TO SEND RECEIVED (variable name) 

RESOURCE (variable name) 

TYPE (PROG) 

LOG DATA (variable name) Data in variable is to 

| | be placed in error logs 

of system supporting 
the LU. 


Figure 5. DIA Use of LU 6.2 Verbs (Part 2 of 2) 
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CHAPTER 5. DIA/LU 6.2 PROTOCOL MACHINES 


The enforcement of the rules specified in this document may be defined by three 
finite state protocol machines which have the following hierarchical 
relationship: 


CONVERSATION FSM 


CONVERSATION 
PROTOCOL 
ENFORCER 


SESSION FSM 


SESSION 
PROTOCOL 
ENFORCER 
COMMAND FSM 


COMMAND 
PROTOCOL 


ENFORCER 


The first protocol machine, Conversation FSM, enforces the DIA use of LU 6.2 
conversational states. It checks the DIA operation to be performed against the 
LU 6.2 state of the DIA process. If the process is in a valid conversational 
state for the requested operation, then a state transition is made, if 
necessary, and the next level of protocol checking in Command FSM occurs. If 
the process is not in a valid conversational state for the requested operation, 
then a protocol error exists in the DIA conversation. 


The second protocol machine, Session FSM, is entered to enforce the DIA session 
protocols. Session FSM determines if the input operation is valid for the 
current DIA session state and invokes the appropriate DIA/LU 6.2 sequence if the 
requested operation affects the setting of DIA session states. If the input 
operation is valid, but only affects the setting of active DIA session states, 
then the next level of protocol checking in the Command FSM takes place. 
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The final protocol machine, Command FSM, enforces the flow control protocols for 
commands which are exchanged within an active DIA session. The appropriate 
DIA/LU 6.2 sequences are indicated for each active command request/reply state 
of the DIA for each valid input operation. | 


The details of these protocol machines are provided in the sections which 
follow. 


The action sequences which are invoked by these machines are defined in the 
section entitled "DIA/LU 6.2 Data Flows", which immediately follows the finite 
state machine descriptions. 
In the following tables each entry is coded as: 

X(Y), /, or 7. 


where: 


X - Specifies the new state (as a numbered column). 
If blank (_), there is no state change. 


Y - S1, S2 ... S89 are labels for command sequence 
which are resultant activity. These lists are 
in the second half table. If Y = FSM2*, then 
further checking in Command FSM is to be done. 


/ or - means error or no action respectively. 
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DIA CONVERSATION FSM 


DIA Conversation State Enforcer: CONVERSATION FSM 


Function 


Verbs Used by 
DIA Transaction 


LU 6.2 Conversation States 


Processes Reset send |Defer |Receive|Confirm| Sync*|Deallo— 
point|cate 

do 
rm [oe fre fom [om [om [mo 
DEALLOCATE with yes no no no no no 
TYPE(SYNC LEVEL) 

DEALLOCATE with yes yes yes yes yes yes 
TYPE (ABEND ) 

DEALLOCATE with no no no no no yes 
TYPE CLOCAL) 

GET ATTRIBUTES otra yes yes yes yes 

0 pe fe fe : 


* LU 6.2 CONVERSATIONS USED BY DIA PROGRAMS DO NOT ENTER THIS STATE 
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Entries in this table are resultant activities defined as follows: 


OUTPUT | FUNCTION 
CODE 


Signal Session FSM; | 


issue DEALLOCATE (ABEND) if the cause of the error cannot be locally 
detected and corrected. 


no Indicates that the input operation should not occur in this state. 
If it does occur, then a process error exists and the program should 


DIA SESSION PROTOCOL MACHINE 


DIA Session State Protocol Enforcer: Session FSM 


Inputs to the Session FSM are DIA commands. 


¢ The DIU data sent or received in the Conversation FSM is further classified 
in Session FSM as to the type of command operation which is being requested. 


° Session FSM deals directly with only those commands which change the session 
state of the DIA process. All other commands are passed through to Command 
FSM as indicated by entry lines labeled OTHER. 


° Prior to entering Session FSM, all semantic and syntactic checks have been 


made on the DIU data. Exception conditions, if any, will appear in this 
machine and Command FSM as inputs to send ACKNOWLEDGE replies with EC codes. 
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ALLOCATE—DIA-—CONV 
DEALLOCATE-—DIA-CONV 


S SIGN-ON SRR REQUEST 
S SIGN-ON NRR REQUEST 
S SIGN-ON NRR REPLY 

S ACK (EC,SON) 


R SIGN-ON SRR REQUEST 
R SIGN-ON NRR REQUEST 
R SIGN-ON NRR REPLY 

R ACK (EC,SON) 


S SIGN-OFF 
R SIGN-OFF 


S OTHER COMMAND 
R OTHER COMMAND 


SEND-DIA—CONFIRM 
REC-—DIA—-CONFIRM 


SEND—DIA-SEND 
REC—DIA-SEND 


RESET |NOTACT | PEND SONS IDLE 
1 2 3 4 5 


QUIET 
10 


2(S3) 
2 


FSM2* 
FSM2* 


~ ~~ mA TMA RL TA TL, TS, 


/ 
5 (FSM2* 


_(S9) 


_(S7) 


~™ OTN “~~ 


NOTE: (*) Calls to Command FSM may sa in transitions to scnee active DIA 


session states (for example, states 5, 6, 


Chapter 5. 


7, 8). 
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OUTPUT | FUNCTION | | : 
CODE : | | 


FSM2 Signal Command FSM; 


(/) Indicates that the input operation should not occur in this state. 
If it does occur, then a process error exists and the program should 


issue DEALLOCATE TYPE (ABEND) if the cause of the error cannot be 
locally detected and corrected. | 


(-) Indicates that the input operation does not result in a state change 


S1 ALLOCATE (TPN = DIA) 
LU 6.2 CONVERSATION STATE = SEND 


52 DEALLOCATE (SYNCPT LEVEL) 
LU 6.2 CONVERSATION STATE = RESET 


$3 SEND DATA (DIU) 
LU 6.2CONVERSATION STATE = SEND 


SEND DATA (DIU) 
RECEIVE AND WAIT 
LU 6.2 CONVERSATION STATE = RECEIVE 


SEND_ERROR 

SEND DATA (ACK (EC) DIU) 
DEALLOCATE (SYNCPT LEVEL) 

LU 6.2 CONVERSATION STATE = RESET 


w~ 


T 


7 RECEIVE AND WAIT 
LU 6.2 CONVERSATION STATE = RECEIVE 


59 CONFIRMED 
LU 6.2 CONVERSATION STATE = RECEIVE 


DIA COMMAND PROTOCOL MACHINE 


DIA Command State Protocol Enforcer: Command FSM 


Function 


FSM2 enforces the command request/reply protocols for command flow within an 
active DIA session. 


The LAST, NOT LAST input values to FSM2 correspond to the Last, Not-Last 
reply indicator value carried in the CORRELATION operand of all DIA replying 
commands. 
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SRRS SRRSR 
6 


CMD REQUEST SRR 

CMD REPLY SRR, NOT LAST 
CMD REPLY NRR, LAST 

ACK (EC,CMD) 


NNANMN 


CMD REQUEST SRR 

CMD REPLY SRR, NOT LAST 
CMD REPLY NRR, LAST 

ACK (EC,CMD) 


AAA Dw 


CMD REQUEST NRR 
CMD REQUEST NRR 


OUTPUT .| FUNCTION 
CODE 


awn 


Indicates that the input operation should not occur in this state. 
If it does occur, then a process error exists and the program should 
issue DEALLOCATE TYPE (ABEND) if the cause of the error cannot be 
locally detected and corrected. 


Indicates that the input operation does not result in a state change 


SEND DATA (DIU) 
LU 6.2 CONVERSATION STATE = SEND 


SEND DATA (DIU) 
RECEIVE AND WAIT 
LU 6.2 CONVERSATION STATE = RECEIVE 


SEND ERROR 

SEND DATA (ACK. (EC) DIU) 
RECEIVE AND WAIT | 
LU 6.2 CONVERSATION STATE = RECEIVE 


SEND_ERROR 
SEND DATA (ACK (EC) DIU) 
LU 6.2 CONVERSATION STATE = SEND 
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CHAPTER 6. DIA/LU 6.2 DATA FLOWS 


As an aid to transaction programmers, detailed explanatory scenarios are 
provided in this section for each of the commands defined by the DIA. Each 
scenario is preceded by a state transition diagram showing the flow of control 
and data for that command operation. 


Conventions used in these scenarios are: 


<XXX> XXX = DIA program state 
| YYY | YYY = DIA architected processing 
LZZ ZZ4 = paraphrased LU 6.2 processing 
or verb usage 
—WWW-—> = paraphrased DIA architected 
or message 
+-WWW-— 
ee = LU 6.2 program notification of 
or issuance of SEND ERROR verb 
Pea | 
* VVV * VVV = illustrative notes 
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SIGN-ON COMMAND 


SENDER OF SIGN-ON 


Idle 
Reset Not Active Pending Active 
RESET SEND RECEIVE SEND 
ISSUE 
ALLOCATE | 
—_—_—_—_——_———»|/Send SIGN-ON 
SRR Req 
—_—_—_—_————>! Rec SIGN-ON 
NRR Reply 
ee 
Rec ACK 
| (EC) Reply 
ISSUE +—_____-___ 
DEALLOCATE 
ee 
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:-DIA State 


:LU 6.2 State 


RECEIVER OF SIGN-ON 


Sign-on Idle 
Reset Not Active Pending Reply Sent Active :DIA State 
RESET RECEIVE SEND RECEIVE RECEIVE >LU 6.2 State 
Allocated 
ee | Rec: SIGN<ON 
SRR Req 
==> (send: SIGN-ON 
NRR Reply 
> 
Send ACK Rec DIU 
(EC) Reply a 
ISSUE ea a 
DEALLOCATE Rec ACK (EC, SON Reply) 


Chapter 6. 


DIA/LU 6.2 Data Flows 


ea 


The following FSM applies to this and all other scenarios below: 


Any Idle Active Idle Active :DIA State 


Any (except © 
reset) Deallocate Reset :LU 6.2 State 


RC=Deallocate 
aaa ete re 


Issue 
Deallocate 
ern 
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DIA SIGN-ON SCENARIO 


CASE1: RECEIVER ACCEPTS SIGN-ON 
DIA TRANS PGM A | DIA TRANS PGM B 


<RESET> 


ALLOCATE 
TYPE (CONVERSATION) 
TPN (DIA) 
<DIA NOT _ACTIVE> 
RECEIVE AND WAIT RC = OK 
<DIA NOT _ACTIVE> 


OK, WHAT REC = DATA «———SIGN-ON SRR REQ-————— SEND DATA 

|PROCESS SIGN-ON CMD| <SET DIA PENDING> 

<SET DIA PENDING> RECEIVE AND WAIT 

SEND DATA —— SIGN-ON NRR REPLY————® OK, WHAT REC = DATA 
<SET SONR_SENT> |PROCESS SIGN-ON REPLY | 
RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
OK, WHAT REC = DATA @——NEXT CND-———-———— SEND-DATA 


<SET DIA IDLE ACTIVE> 
|PROCESS CMD REC. | 


oO 
O 
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DIA SIGN-ON SCENARIO 
CASE2: RECEIVER REJECTS SIGN-ON 


DIA TRANS PGM A 


<DIA NOT_ACTIVE> 
RECEIVE AND WAIT 


OK, WHAT REC = DATA «——SIGN-ON SRR REQ 
|PROCESS SIGN-ON CMD] 


**SESSION PARAMETERS** 
NOT SUPPORTED 


SEND ERROR SS 


SEND DATA ——-ACK NRR (EC)———————> 


<SET DIA NOT_ACTIVE> 


DEALLOCATE SS ee 
TYPE (SYNC LEVEL) 


_ <DIA RESET> 
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DIA TRANS PGM B 


<RESET> 


ALLOCATE 
TYPE (CONVERSATION) 
TPN (DIA) 
RC = OK 
<DIA NOT ACTIVE> 
SEND DATA 
<SET DIA PENDING> 


RECEIVE AND WAIT 


RC = PGM ERROR 


RECEIVE AND WAIT 
OK, WHAT REC = DATA 


|PROCESS ACK REPLY| 
<SET DIA NOT ACTIVE> 
RECEIVE AND WAIT 

OK, WHAT REC = 

| CONFIRM 


CONF TERMED 


RECEIVE AND WAIT 
RC = DEALLOCATE _ 
NORMAL 


DEALLOCATE 


<DIA RESET> 


DIA SIGN-ON SCENARIO 
CASE3: SENDER ACCEPTS NEGOTIATED SIGN-ON REPLY 


DIA TRANS PGM A DIA TRANS PGM B 


<RESET> 


ALLOCATE 
TYPE (CONVERSATION) 
TPN (DIA) 
<DIA NOT ACTIVE> 
RECEIVE AND WAIT RC = OK 
<DIA NOT ACTIVE> 


SIGN-ON SRR REQ 
OK, WHAT REC = DATA «#————————————_ SEND DATA 

FS (3B,4B,6AB) 
|PROCESS SIGN-ON CND| <SET DIA PENDING> 
<SET DIA PENDING> RECEIVE AND WAIT 


“FS 3A,4A Supported* 
*“FS 6AB Not Supported* 


RECEIVE AND WAIT 
OK, WHAT REC = SEND 


SIGN-ON NRR REPLY 


SEND DATA $$$ $$» OK, WHAT REC = DATA 
FS (3A,4A) 
<SET SONR SENT> |PROCESS SIGN-ON REPLY| 
RECEIVE AND WAIT SUBSET ACCEPTABLE 
SET FUNCTION SET 
= 3B, 4B. 


<SET DIA IDLE ACTIVE> 


OK, WHAT REG = DATA. —————=—NEXT OD ——————————— SEND-DATA 
<SET DIA IDLE ACTIVE> 
|PROCESS CMD REC. | 


O 
oO 


Chapter 6. DIA/LU 6.2 Data Flows 35 


DIA SIGN-ON SCENARIO 


CASE4: SENDER REJECTS NEGOTIATED SIGN-ON REPLY 


DIA TRANS PGM A 


<DIA NOT_ACTIVE> 
RECEIVE _AND WAIT 


SIGN-ON SRR REQ 


OK, WHAT REC = DATA <<——$—$—$—$$___________— 
| FS (2B,5B,8B) 
|PROCESS SIGN-ON CMD] 


<SET DIA PENDING> 
*FS 2A,5A Supported* 
*FS 8A Not Supported* 


SIGN-ON NRR REPLY 


en a PSR AN a DE SE SP SE STREET 


FS (2A,5A) 


SEND_DATA 

<SET SONR SENT> 
RECEIVE AND WAIT 
RC = PGM ERROR 


RECEIVE AND WAIT 
OK, WHAT REC = DATA —— ACK (EC) (COR) 


|PROCESS ACK REPLY| 
<SET DIA IDLE ACTIVE> 
RECEIVE AND WAIT 


OK, WHAT REC = 
CONFIRM 


(ed 


CONFIRMED 


RC = OK 
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DIA TRANS PGM B 


<RESET> 


ALLOCATE | ; 
TYPE (CONVERSATION) 
TPN (DIA) 


RC = OK 
<DIA NOT ACTIVE> 


SEND DATA 


<SET DIA PENDING> 


RECEIVE AND WAIT 


OK, WHAT REC = DATA 
|PROCESS SIGN-ON REPLY| 
|SUBSET NOT ACCEPTABLE | 


SEND ERROR 


SEND DATA 


<SET DIA NOT _ACTIVE> 


DEALLOCATE 
TYPE (SYNC_LEVEL) 


<DIA RESET> 


RECEIVE AND WAIT 
RC = DEALLOCATE NORMAL 


DEALLOCATE 
RC = OK 


<DIA RESET> 


DIA SIGN-ON SCENARIO 


CASE5: RECEIVER ACCEPTS MID-SESSION SIGN ON NRR REQUEST 
(This case is allowed only with Function Set 7 for migration) 


DIA TRANS PGM B | DIA TRANS PGM A 
<DIA IDLE-ACTIVE> | <DIA IDLE ACTIVE> 


<ACTIVE FS = 7B> | <ACTIVE FS = 7A> 


*PROCESS SENDS MID- 
SESSION SIGN-ON NRR 
‘TO CHANGE ROLES* 
RECEIVE AND WAIT 
SIGN-ON NRR REQ 
OK, WHAT REC = DATA «——————___ SEND DATA 


FS (7B) 
|PROCESS SIGN-ON CMD| <SET DIA SONS> 
ROLE CHANGE ACCEPTABLE RECEIVE AND WAIT 
SET FS PARM = 7A 
<SET DIA IDLE ACTIVE> 
SET FS PARM = 7B 
NEXT CMD 
SEND DATA $$$ > 0K, WHAT REC = DATA 


<DIA IDLE-ACTIVE> 


|PROCESS CMD RECEIVED | 
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SIGN-OFF COMMAND 


SENDER OF SIGN-OFF 


Idle Not Active Reset _ :DIA STATE 
Active | 
SEND _ SEND | RESET :LU 6.2 STATE 


Send SIGN-OFF NRR 
iii ia aa i 


ISSUE 
DEALLOCATE 
———$_________» 


RECEIVER OF SIGN-OFF 


Idle | Not Active Reset :DIA STATE 


Active 
RECEIVE RECEIVE RESET :-LU 6.2 STATE 


Receive SIGN-OFF NRR 
sincere 


RC = DEALLOCATE_ 
NORMAL 

ii it ial 

ISSUE 

DEALLOCATE 
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DIA SIGN-OFF SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE | DIA IDLE ACTIVE 


RECEIVE AND WAIT 
OK, WHAT REC = DATA | «—————SIGN-OFF NRR———————_. SEND_DATA 


|PROCESS SIGN-OFF | <DIA NOT ACTIVE> 
<DIA NOT ACTIVE> 


RECEIVE AND WAIT 


OK, WHAT REC = $$$ DEALLOCATE 
CONFIRM TYPE (SYNC LEVEL) 
CONFIRMED ORC = OOK 
RC = OK | 
RECEIVE AND WAIT _ <DIA RESET> 
RC = DEALLOCATE_ NORMAL 
DEALLOCATE 
RC = OK 


<DIA RESET> 
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SEND-ERROR SEQUENCES 


DIU RECEIVER FSM 


Idle | Command Idle 
Active -— Dependent Active DIA State 


RECEIVE SEND RECEIVE :LU 6.2 State 


error detected 


Issue SEND-ERROR 
a ae et ar ee eee TTS 


Send ACK NRR 
erence 


DIU SENDER FSM 


Command Idle Idle 
Dependent Active Active :DIA State 


SEND SEND SEND :LU 6.2 State 


send 
Type 2 Suffix 
REAR ree ae eS TE 


Issue 
SEND-ERROR 
| 
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SEND-ERROR SCENARIOS 


EXCEPTIONS DETECTED BY DIU RECEIVER 


RECEIVE AND WAIT 
OK, WHAT REC = DATA 


*SERROR DETECTED** 


RC = PGM ERROR $$ _______———_ SEND-ERROR 
RECEIVE AND WAIT 
OK, WHAT REC = DATA 
: ACK (CORR) (EC) 
SEND DATA 


RECEIVE AND WAIT 
EXCEPTION CONDITIONS DETECTED BY THE DIU SENDER 


SEND DATA (PREFIX) 
SEND DATA (COMMAND) 
“ERROR DETECTED*** 


SEND-ERROR | _—_— RC = PGM ERROR 


*ABANDON EFFORTS 
TO PARSE DIU* 


RECEIVE AND WAIT 
SUFFIX TYPE 2 


SEND_DATA $$$ 0K, WHAT _REC = DATA 
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OBTAIN COMMAND 


SENDER OF OBTAIN 


Idle SRR 7 SRR sent and 
Active oe sent SRR received 


SEND ~ | RECEIVE SEND 


Send OBTAIN SRR | : 
Lent | Receive DELIVER SRR 
(SE EA ARE ET RSA 
not last 


Send ACK NRR (DEL) 
a a a eT TO ERT 


Receive DELIVER SRR 
eee 
Not last 


send ACK NRR (DEL) 
Receive ACK NRR (OBTAIN) |\*——————""— 
ae ac haan 


last 


RECEIVER OF OBTAIN 


Idle | SRR SRR received 
Active received | and SRR sent 
RECEIVE SEND RECEIVE 


Receive OBTAIN SRR 
Lene | Sand DELIVER SRR 
aS 


not last 


Receive ACK NRR (DEL) 
Pn Ser Se ae ee 


Send DELIVER SRR 
a 
not last 


Receive ACK NRR (DEL) 


Send ACK NRR (OBTAIN) —_—_—_—_———- n—neeeeeeee 
Ea aaInanEREndnenmieeianemeemaemememmmemmmmeeeeeees last 
last 
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:DIA STATE 


>LU 6.2 STATE 


:DIA STATE 


—:LU 6.2 STATE 


DIA OBTAIN SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «————— OBTAIN SRR ————————_ SEND_ DATA 

|PROCESS OBTAIN CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA DELIVER SRR REPLY—————> OK, WHAT REC = DATA 
<SET SRR RECEIVED/SENT> |PROCESS DEL. REPLY| 
RECEIVE AND WAIT <SET SRR SENT/RECEIVED> 


OK, WHAT REC = SEND 


OK, WHAT REC = DATA «———ACK (DELIVER) ——————— SEND DATA 
_|PROCESS ACK REPLY | <RESET TO SRR SENT> 
<RESET TO SRR RECEIVED> RECEIVE AND WAIT 


CONTINUE OBTAIN PROCESS 
O 
fe) 

ALL DOCUMENTS DELIVERED 


SEND DATA ———— ACK (OBTAIN) —————--> OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK REPLY | 
RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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LIST COMMAND 


SENDER OF LIST 


Idle SRR SRR sent and :-DIA STATE 
Active sent SRR received 
SEND ~ RECEIVE SEND :-LU 6.2 STATE 


Send LIST SRR 
ee | Roaceive DELIVER SRR 


ee 
not. last 


send ACK NRR (DEL) 


cei ac 
Receive ACK NRR (LIST) 


or 
last 


RECEIVER OF LIST 


Idle | | SRR SRR received. :DIA STATE 
Active received and SRR sent 


RECEIVE SEND | RECEIVE :LU 6.2 STATE 


Receive LIST SRR 
_—_— OO || Send DELIVER SRR 


Scena RE A PR OLE EL EDTA 
not last 


Receive ACK NRR (DEL) 
insincere nnieeicilet 


Send ACK NRR (LIST) 


rere creer ereteneenencerrerenaenemree AeA 
last 
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DIA LIST SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «#———— LIST SRR ——————_ SEND _DATA 
|PROCESS LIST CMD] <SET SRR SENT> 
<SET SRR RECEIVED> RECEIVE AND WAIT 


OK, WHAT REC = SEND 


DELIVER SRR REPLY————— OK, WHAT REC = DATA 


SEND DATA 

<SET SRR RECEIVED/SENT> _ |PROCESS DEL. REPLY| 
RECEIVE AND WAIT <SET SRR SENT/RECEIVED> 
OK, WHAT REC = DATA 4———ACK (DELIVER) ——————— SEND DATA 

|PROCESS ACK REPLY | <RESET TO SRR SENT> 
<RESET TO SRR RECEIVED> | RECEIVE AND WAIT 

SEND DATA ——— ACK (LIST) ———————> OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK REPLY | 
RECEIVE_AND WAIT _ <SET DIA IDLE ACTIVE> 
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REQUEST-DISTRIBUTION COMMAND 


SENDER OF REQUEST-DISTRIBUTION 


Idle | SRR :DIA STATE 
Active | sent 


SEND RECEIVE >LU 6.2 STATE 


Send REQUEST-DISTRIBUTION 


SRR 
<i iii imei aint 


Receive ACK NRR (REQDIST) 


scare cere ert nieces eee Am ET SDAA 


last, REPLY-DATA 


RECEIVER OF REQUEST-DISTRIBUTION 


Idle SRR :DIA STATE 
Active Received | 
RECEIVE SEND :-LU 6.2 STATE 


Receive REQUEST-DISTRIBUTION 
SRR 


a ene Se eA eS Ee TN De TEN TT a 


Send ACK NRR (REQ DIST) 


en] 


last, REPLY-DATA 
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DIA REQUEST-DISTRIBUTION SCENARIO 


DIA TRANS PGM A | DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «—— REQ DIST SRR ———————__ SEND DATA 

|PROCESS REQ DIST| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 
SEND DATA ACK (REQ DIST) ————— OK, WHAT REC = DATA 


(REPLY DATA) 
<SET DIA IDLE ACTIVE> |PROCESS ACK] 


RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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Active 


RECEIVE 


CANCEL-DISTRIBUTION COMMAND 


SENDER OF CANCEL-DISTRIBUTION 


Idle SRR 


Active | sent 


3 | 


RECEIVE 


SEND 


Send CANCEL-DISTRIBUTION 
| SRR 


ec ra i AS ORNS ETT 


Receive ACK NRR (CANDIST) 


cea cen RAL ECG BESET IES SETITEET 


last 


RECEIVER OF CANCEL-DISTRIBUTION 


Idle 


Receive CANCEL-DISTRIBUTION 
SRR 


dean nese ee a ERP OE SIRES UES SE PAC TOOES 


Send ACK NRR (CANDIST) 
I li iia 


last 
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SRR 
received 


SEND 


:DIA STATE 


:LU 6.2 STATE | 


-DIA STATE 


>LU 6.2 STATE 


DIA CANCEL-DISTRIBUTION SCENARIO 
DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «——— CANCEL DIST SRR ————— SEND DATA 

|PROCESS CANC_DIST| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 
‘SEND DATA ACK (CANC DIST) ———————> OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK| 


RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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STATUS-LIST COMMAND 


SENDER OF STATUS-LIST 


Idle Active | :DIA STATE 
Active Idle 
SEND RECEIVE — :LU 6.2 STATE 


Send STATUS-LIST NRR 


aS gE A TE SE SCD 


RECEIVE AND WAIT 


RECEIVER OF STATUS-LIST 


Idle : Active | :DIA STATE 
Active Idle 
RECEIVE SEND | | :LU 6.2 STATE 


Receive STATUS-LIST NRR 


Aer st TED AR TESS NTE A NEALE 


Receive SEND 
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DIA STATUS-LIST SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE | DIA IDLE ACTIVE 


RECEIVE AND WAIT 


SEND DATA STATUS-LIST NRR —————» OK, WHAT_REC = DATA 


RECEIVE AND WAIT PROCESS STATUS 
| LIST COMMAND 
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PROCESS-BIT-STRING COMMAND 


SENDER OF PROCESS-BIT-STRING 


Idle | SRR . >-DIA STATE 
Active sent i 
SEND RECEIVE | | | : LU 6.2 STATE 


Send PROCESS-BIT-STRING 
| SRR 
(eS EEE TESST AE LEST ESCO SEAT 


Receive ACK NRR (PBS) 
errr tereseenn nett ESR CEERO PSE 


last 


RECEIVER OF PROCESS-BIT-STRING 


Idle | | SRR | ‘DIA STATE 
Active received 


RECEIVE SEND :LU 6.2 STATE 


Receive PROCESS-BIT-STRING 


SRR 
00a al 


Send ACK NRR (PBS) 
eR a a Le TE 


last 
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DIA PROCESS-BIT-STRING SCENARIO 


DIA TRANS PGM A | DIA TRANS PGM B 


DIA IDLE ACTIVE | DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «—— PBS SRR ———————————_ SEND _ DATA 

|PROCESS PBS CMD| <SET SRR SENT> 

<SET SRR RECEIVED> | RECEIVE AND WAIT 

SEND DATA ACK (PBS) ————————> OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> | |PROCESS ACK| 

RECEIVE _AND WAIT <SET DIA IDLE ACTIVE> 
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DELIVER COMMAND 


SENDER OF DELIVER 


Idle | SRR :DIA STATE 
Active sent | 
SEND > : RECEIVE :LU 6.2 STATE 


Send DELIVER SRR 
SR etree tence errata ed vena none BNE NC 


Receive ACK NRR (DEL) 
Ee eee RS er et ete ee ee et 
last 


RECEIVER OF DELIVER — 


Idle SRR :DIA STATE 


Active received 
RECEIVE SEND | >LU 6.2 STATE 


Receive DELIVER SRR 
Ee Le eS ROS LE een TONS re er CTE 


Send ACK NRR (DEL) 
Ce en erent Ae re Neem Ne BEET AN See 


last 
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DIA DELIVER SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


SEND DATA DELIVER SRR—————————>_ OK, WHAT REC = DATA 
<SET SRR SENT> |PROCESS DELIVER| 
RECEIVE AND WAIT <SET SRR RECEIVED> 
OK, WHAT REC = DATA ¢#—— ACK (DELIVER) ——————— SEND DATA 

|PROCESS ACK| <SET DIA IDLE ACTIVE> 
<SET DIA IDLE _ACTIVE> RECEIVE AND WAIT 
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FILE COMMAND 


SENDER OF FILE 


Idle | SRR | :DIA STATE 
Active sent 
SEND | RECEIVE : -LU 6.2 STATE 


Send FILE SRR 


en eae 


Receive ACK NRR (FILE) 
perms ma TERPS III LSE SL PS EEE, 


last, REPLY-DATA 


RECEIVER OF FILE 


Idle SRR : -:DIA STATE 
Active | received | 
RECEIVE SEND | :LU 6.2 STATE 


Receive FILE SRR 


Ce 


Send ACK NRR (FILE) 
SN 


last, REPLY-DATA 
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DIA FILE SCENARIO 
DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «————— FILE SRR ————————__ SEND DATA 

|PROCESS FILE CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA | ———— ACK (FILE) ——————> OK, WHAT REC = DATA 
(REPLY DATA) 

<SET DIA IDLE ACTIVE> |PROCESS ACK| 

RECEIVE AND WAIT _ <SET DIA IDLE ACTIVE> 
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RETRIEVE COMMAND 


SENDER OF RETRIEVE 


Receive RETRIEVE SRR 
eee ee eae ee OE LR LN 


Send DELIVER NRR 
So 
last 
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Idle SRR :DIA STATE 
Active _ sent 
_ SEND _ RECEIVE :LU 6.2 STATE 
“Send RETRIEVE SRR 
| Receive DELIVER NRR 
— SS 
last. 
RECEIVER OF RETRIEVE 
Idle SRR :DIA STATE 
Active received 7 
RECEIVE _ SEND :LU 6.2 STATE 


DIA RETRIEVE SCENARIO 1 


(DOCUMENT DELIVERED NRR) 


DIA TRANS PGM A. DIA TRANS PGM B. 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «—— RETRIEVE SRR ——————— SEND DATA 

|PROCESS RETRIEVE] | <SET SRR SENT> 

<SET SRR RECEIVED> | RECEIVE _AND_WAIT 

SEND DATA DELIVER NRR ———————» OK, WHAT_REC = DATA 
REPLY LAST 

<SET DIA IDLE ACTIVE> |PROCESS DELIVER REPLY| 

RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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~SEARCH COMMAND 
SENDER OF SEARCH 


(NO DOCUMENTS FOUND CASE) 


Idle SRR -DIA STATE 
Active | : sent 


SEND RECEIVE a | :LU 6.2 STATE 


Send SEARCH SRR 


Receive ACK NRR 


a 


last, Reply-Data 


RECEIVER OF SEARCH 


Idle | SRR - :DIA STATE | 


Active received 
RECEIVE SEND  :LU 6.2 STATE 


Receive SEARCH SRR 


send ACK NRR 


pores tm EE TE I EEE IESE PNET TOS IE SEES 


last, Reply-Data 
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DIA SEARCH SCENARIO 1 


(NO DOCUMENTS FOUND CASE) 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA #————— SEARCH SRR ————————__ SEND DATA 

|PROCESS SEARCH CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA ————— ACK (SEARCH) ————————> OK, WHAT REC = DATA 
(REPLY DATA) 

<SET DIA IDLE ACTIVE> |PROCESS ACK] 


RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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SENDER OF SEARCH 


(DOCUMENTS FOUND CASE) 


Idle SRR : :DIA STATE 
Active sent 
SEND RECEIVE ' | :LU 6.2 STATE 


Send SEARCH SRR 


Receive DELIVER NRR 
orescence TTT CATRCAETE 


last 


RECEIVER OF SEARCH 


Idle SRR >DIA STATE 
Active received 


RECEIVE | SEND :LU 6.2 STATE 


Receive SEARCH SRR 


rsa tn CES CE ER HOA ERASED 


Send DELIVER NRR 


OG recerr eee re cr ncsescren serene neces nsensneienevesnennsone ener ANAS 
last 
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DIA SEARCH SCENARIO 2 


(DOCUMENTS FOUND CASE) 
DIA TRANS PGM A DIA TRANS PGM B 
DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA  4#—————— _ SEARCH SRR ————————-_ SEND _DATA 


|PROCESS SEARCH CMD | <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA ———— DELIVER NRR ~————— OK, WHAT REC = DATA 
REPLY LAST 

<SET DIA IDLE ACTIVE> | |PROCESS DELIVER | 

RECEIVE AND WAIT | <SET DIA IDLE ACTIVE> 
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DELETE COMMAND 
SENDER OF DELETE 


Idle SRR -DIA STATE 


Active _ sent 
SEND | RECEIVE | . -LU 6.2 STATE 


Send DELETE SRR 
I a es 


Receive ACK NRR (DEL) 
eee 


last 


RECEIVER OF DELETE 


Idle . SRR | -DIA STATE 


Active received 
RECEIVE SEND :LU 6.2 STATE 


Receive DELETE SRR 
ag PAD A SRD PT SP EOC” 


Send ACK NRR (DEL) 
eae 


last 


64 DIA: Transaction Programmer's Guide 


DIA DELETE SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 

DIA IDLE ACTIVE DIA IDLE ACTIVE 

OK, WHAT REC = DATA «———— DELETE SRR ——————— SEND DATA 

|PROCESS DELETE CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA —————ACK (DELETE) ——————* OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK| 

RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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FORMAT COMMAND 
SENDER OF FORMAT 


(FORMAT AND FILE CASE) 


Idle SRR oe -- :DIA STATE 
Active sent 
SEND RECEIVE -LU 6.2 STATE 


Send FORMAT SRR 


2 eee eT SESE A CE SP TEEPE ACSC 


Receive ACK NRR (FMT) 
Alper re RETR ALTRI ERIE ERI IED IE TEED FEAL ERATED 


last, Reply-Data 


RECEIVER OF FORMAT 


Idle SRR | :DIA STATE 
Active received 
RECEIVE | SEND :LU 6.2 STATE 


Receive FORMAT SRR 


Send ACK NRR (FMT) 
ct a ee Ee a ae ae ER TOE 


last, Reply-Data 
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DIA FORMAT SCENARIO 1 


(FORMAT AND FILE) 


DIA TRANS PGM A 


DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «+———— FORMAT SRR 


|PROCESS FORMAT CMD| 
<SET SRR RECEIVED> 


SEND DATA 


<SET DIA IDLE ACTIVE> 


RECEIVE AND WAIT 


ACK (FORMAT) -—--—--—> 


(REPLY DATA) 


Chapter 6. 


DIA TRANS PGM B 


DIA IDLE ACTIVE 


SEND DATA 
<SET SRR SENT> 
RECEIVE AND WAIT 


OK, WHAT REC = DATA 


|PROCESS ACK| 


<SET DIA IDLE ACTIVE> 
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SENDER OF FORMAT 


(FORMAT AND DELIVER CASE) 


Idle SRR on :DIA STATE 
Active sent 
SEND | | RECEIVE | ) ‘LU 6.2 STATE 


Send FORMAT SRR 
aa i a a aS 


| Receive DELIVER NRR 
5 en 
last 


RECEIVER OF FORMAT 


Idle _ SRR :DIA STATE 


Active received 
RECEIVE SEND —:LU 6.2 STATE 


Receive FORMAT SRR 
RR A SP RS ES EPR ED AGP PON ETA 


Send DELIVER NRR 
ca ai aaa 


last 
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DIA FORMAT SCENARIO 2 


(FORMAT AND DELIVER NRR) 


DIA TRANS PGM A | DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «————— FORMAT SRR ———————_ SEND DATA 

|PROCESS FORMAT CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA ————— DELIVER NRR —————»> OK, WHAT REC = DATA 
REPLY LAST 

<SET DIA IDLE _ACTIVE> |PROCESS DELIVER| 

RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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MODIFY COMMAND 


SENDER OF MODIFY 


fie. | SRR DIA STATE 
Active . sent 
SEND RECEIVE ‘LU 6.2 STATE 


Send MODIFY SRR 
nseonoresenennetasnonenennaneasensaneyamsesnsyneanstnreneiseneneasemnaaenenesena > 


Receive ACK NRR (MOD) 
lc ek aoc 


last 


RECEIVER OF MODIFY 


Idle. a SRR | Ss DIA STATE 
Active © | received | 


RECEIVE SEND : LU 6.2 STATE. 


Receive MODIFY SRR 
cere a Ra ee ee ee 


Send ACK NRR (MOD) 
, 


last 
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DIA MODIFY SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «———— MODIFY SRR —————— SEND DATA 

|PROCESS MODIFY CMD| <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 
SEND DATA ————— ACK (MODIFY) ———~———> OK, WHAT _REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK| 


RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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EXECUTE COMMAND 
SENDER OF EXECUTE 


Idle = SRR :DIA STATE 


Active sent 
SEND RECEIVE a -LU 6.2 STATE 


Send EXECUTE SRR 
at che a ig 


Receive ACK NRR (EXEC) 
ishing 


last 


RECEIVER OF EXECUTE 


Idle SRR :-DIA STATE 
Active received 
RECEIVE SEND :-LU 6.2 STATE 


Receive EXECUTE SRR 
la a al rience 


Send ACK NRR (EXEC ) 
aa 


last 
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DIA EXECUTE SCENARIO 


DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE ~ DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA #——— EXECUTE SRR ———— SEND DATA 

|PROCESS EXECUTE CMD | <SET SRR SENT> 

<SET SRR RECEIVED> RECEIVE AND WAIT 

SEND DATA women ACK (EXECUTE) —————> OK, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK| 

RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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SET-CONTROL-VALUE COMMAND 


SENDER OF SET-CONTROL-VALUE 


Idle | SRR :DIA STATE 
Active sent . 
SEND RECEIVE —_ «SEU 6.2 STATE 


Send SCV SRR 
| | 


Receive ACK NRR (SCV) 
PP ee ee TE ee TO 
last 


RECEIVER OF SET-CONTROL-VALUE 


Idle SRR :DIA STATE 
Active | received | 
RECEIVE : | SEND  :LU 6.2 STATE 


Receive SCV SRR 
| | 


Send ACK NRR (SCV) 
erence eset cA SR EE SEIT PSTD 
last 
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DIA SET-CONTROL-VALUE SCENARIO 
DIA TRANS PGM A DIA TRANS PGM B 


DIA IDLE ACTIVE DIA IDLE ACTIVE 


RECEIVE AND WAIT 


OK, WHAT REC = DATA «#——— SCV SRR ———————-__ SEND DATA 

|PROCESS SCV CMD| <SET SRR SENT> 

<SET SRR RECEIVED> | RECEIVE AND WAIT 

SEND DATA ACK (SCV) --—-———-->—>——-—> 0K, WHAT REC = DATA 
<SET DIA IDLE ACTIVE> |PROCESS ACK| 

RECEIVE AND WAIT <SET DIA IDLE ACTIVE> 
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GLOSSARY 


access code. A 4-byte decimal 
value, assigned to a document by 
the primary owner, that determines 
the set of users allowed to access 
the document. 


address. (1) A character or 
group of characters that 
identifies a register, a 
particular part of storage, or 
some other data source or 
destination. (2) In DIA, a 1- to 
8-byte character string that 
identifies the logical components 
of an office system network. 
These logical components are: 
source nodes, recipient nodes, and 
office system nodes. 


affinity. A defined relationship 
that permits the DIA resources of 
a source or recipient to be 
accessed on his behalf by another 
user. 


application processing 
services. The set of services 
that provide DIA functions 
enabling users to access 
processing capabilities of a 
remote node. 


ARR. Asynchronous reply 
required. 


asynchronous reply required 
(ARR). A command class that 
requests asynchronous processing 
and reply of a DIA function. 
COD. Confirmation-of-delivery. 
command. The function to be 


performed by the receiving DIA 
process. 


command sequence. A DIU data 
stream component containing a set 
of one or more commands. 


condition code. Defines the 
specific exception condition 
detected by the receiver of a DIU. 


confirmation -of-delivery 

(COD). An asynchronous message 
returned to the source node of a 
distribution request that 
indicates the information 
distributed has been delivered to 
the recipient node. 


control variable. A DIA entity 
maintained by a DIA process for 
the purpose of verification and 
authorization. 


correlation value. Information 
used to uniquely identify and 
correlate the request to the 


reply. 


data unit. A DIU data stream 
component that contains 
information referenced by operands 
of a command in the DIU. 


data variable. A variable length 
collection of information 
contained in a structured field. 


destination node. The office 
system node that provides services 
for attached source and recipient 
nodes. 


DIA. Document interchange 
architecture. 


DIA session. A logical 
connection between two DIA 
processes that is used to exchange 
information. 


distribution. In general, the 
function provided by DIA of 
transporting information from a 
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source node to one or more 
recipient nodes. 


distribution document name. A 
unique identifier assigned to each 
distribution request. 


distribution library. The 
collection of distribution queues 
and data storage provided by an 
office system node for the purpose 
of document distribution. 


distribution queue. A queue of 
distribution and status 
information to be delivered to 
source or recipient nodes. 


distribution system. The 
collection of office system nodes, 
source nodes, and recipient nodes 
that are interconnected to form an 
office system network. 

DIU. Document interchange unit. 
DIU component. A self-defining, 
variable length structured field. 
The DIU components are: prefix, 


command sequence, data unit, 
document unit, and suffix. 


DIU subcomponent. A 
self-defining, variable length 
structured field contained within 
a DIU component. 


document. (1) (ISO) A data 
medium and the data recorded on 
it, that generally has permanence 
and that can be read by man or 
machine. (2) A unified collection 
of information pertaining to a 
specific subject or related 
subjects. 


document content introducer. The 
DIU data stream subcomponent that 
identifies the beginning of the 
document content. 


document descriptor. A set of 
profile parameters describing a 


document that satisfied a document 
library search request. 


document descriptor document. A 
collection of one or more document 


descriptors. 


document distribution 
services. The set of services 
that provide DIA functions 
enabling users to distribute 
information in a distribution 
system. 


Document Interchange 
Architecture (DIA). The 
specification of rules and data 
streams necessary to interchange 
information in a consistent, 
predictable manner. 


document interchange unit 

(DIU). The basic unit of 
information exchanged between DIA 
processes. 


document library. A repository 
on which documents and document 
related information is stored. 


document library services. The 
set of services that provide DIA 
functions enabling users to manage 


the contents of a document 


library. 


document type. A classification 
that identifies the structure and 
format of a document. 


document unit. <A DIU data stream 
component that contains the 
document and related document 
information. 


document unit identifier. The DIU 
data stream subcomponent that 
contains the document type and 
system code identifier of the 
document. 


end user. (1) The ultimate 
source or destination of 
information flowing through a 
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system. (2) In DIA, a program, 
device, person, or system that 
uses DIA for the purpose of 
information interchange. 


exception condition class. The 
type of exception condition 
detected by the receiver of a DIU. 
The exception classes are: 
session, syntax, semantic, 
process, and sender. 


exception condition data. A field 
containing the DIU data stream 
component or subcomponent that 
caused the exception condition. 


exception condition object. An 
identifier of the DIU component or 
subcomponent that caused the 
exception condition. 


format byte. That part of the 
Structure field introducer that 
defines the format and content of 
the structured field data 
variable. 


function set. The set of commands 
that identify the scope of work. 
Function sets have been defined so 
that each set contains all 
commands required for a 
well-defined, usable, and complete 
set of functions for a given 
category of services. 


GCID. Graphic character set ID. 


graphic character set ID 
(GCID). The registry for graphic 
character sets and code pages. 


ID. That part of the structured 
field introducer that defines the 
class and type of the structured 
field. 


IDP. Interchange document 
profile. 


Interchange Document Profile 
(IDP). A set of descriptors that 
identify and describe a document. 


introducer. A 5-byte structured 
field identifier. The introducer 
contains a 2-byte length field, a 
2-byte ID, and a format byte. 


introducer extension. An optional 
extension to the structured field 
introducer used for segmentation 
of the structured field. 


ISS. Introducer extension. 


LADN. Library assigned document 
name. 


library assigned document name 
(LADN). A unique name assigned 
to documents filed in the document 
library. 


message. A collection of 
information transmitted from one 
point to another. 


No reply required (NRR). A 
command class used when the 
function requested does not 
require a reply. 


NRR.. No reply required. 


office system node. The DIA 
process that provides the services 
for attached source or recipient 
nodes. | | | 


operand. (1) (ISO) An entity to 
which an operation is applied. 

(2) A data stream subcomponent 
that controls the execution of the 
command. 


originating node. The office 
system node that provides services 
for attached source nodes. 


OSN. Office system node. 


owner-delegate. A user that is 
designated as secondary owner by 
the primary owner of the document 
in the document library. 
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password. A character string 
used for validation and 
authorization to gain access to a 
resource. | 


personal. A distribution class of 
service that requires the 
recipient to supply a password to 
receive the distributed 
information. 


prefix. The DIU data stream 
component that introduces and 
identifies the DIU. 


primary owner. The user who 
files the document in the document 
library. 


priority. A distribution class of 
service that prioritizes the 
distributions so information of 
higher priority is delivered 
before information of lower | 
priority. 


process. (1) A systematic 
sequence of operations to produce 
a specified result. (2) In DIA, a 
program that uses the DIA rules 
and data structures to eUUorenauee 
information. 


profile parameter. <A field of a 
subprofile that identifies and 
describes the document. 


recipient. An end user that 
receives information in an office 
system network. 


recipient node. A DIA logical 
component that provides services 
on behalf of recipients. 


recovery action. The procedure 
recommended by the process that 
detected an exception condition. 


reply. A command that is used to 
respond to a previous ly received 
request. 


request. A command that 
specifies a function to be 
performed. 


search argument. A search 
selection criterion that contains 
the profile parameter identifier, 
the search data value, and the 
search comparison operator. 


search data parameter set. A 
collection of one or more search 
data parameters and the logical 
operators used to relate them. 


search result list. A user named 
object that contains references to 
documents selected by the SEARCH 
command process. 


segmentation. The division of a 
DIU data stream component into two 
Or more segments. 


source. An end user that 
requests services in an office 
system network. 


source node. A DIA logical 
component that provides services 
on behalf of sources. 

SRR. Synchronous reply required. 
structured field. A 
self-defining, variable length 
field comprised of an introducer, 


an optional introducer extension, 
and a data variable. 


subprofile. A set of profile 
parameters that describe the 
characteristics and attributes of 
a document. 


suffix. The DIU data stream 
component that terminates the DIU. 


synchronous reply required 
(SRR). A command class that 


requests synchronous processing 


and reply of a DIA function. 
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system code. An identifier 
associated with the originator of 
the document that is contained in 
a DIU document unit. 


user. 


See end user. 
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